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RECilVED 
NOV I 6 2008 

REMARKS 

Claims 1-6, 8-16, and 18-24 are all the claims ptsnding in the appUcation. Claims 1-22 
stand ngected on prior art grounds. Claims 1-19 and 2 1 -22 stand rejected upon informalities. 
Claims 7 and 1 7 are cancelled herein without prejudice or disclaimer. Claims 23 and 24 ; 
added. Claims 1, 5, 9. 1 1, 15, 19. 21. and 22 are amended herein. Applicants rcspectfiiUy 
traverse these rejections based on the following discussion. 



rare 



I. The Objections to the Drawings 

The drawings are objected to as foiling to comply with 37 CFR 1.84(pX5) because they 
do not include the foUowing reference sign mentioned in the description: "70". Accordingly, 
the AppUcants have amended the specification to remove the inadvertent inclusion of the 
reference number '70" and the associated description thereof. In view of the foregoing, the 
Examiner is respectfuUy requested to reconsider and withdraw this objection. 

IL The 35 U.S.C. §112, First Paragraph, Rejection 

Claims 1-19 and 21-22 stand rejected under 35 U.S.C. §112, first paragraph. These 
rejections are traversed as explained below. The Office Action concludes that the claimed 
'building a list of a sequence of said static and dynamic structures" and "building multiple 
repeating dynamic structures at runtime" are not adequately described in the specification. 
However, the rtgections given in the Office Action prima facie defective according to the 
Federal Circuit in Fjeys v. Suffanp, 984 F.2d 1 164, 25 USPQ 2d 1601, 1607 (Fed. Cir. 1993) 
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(quotiiig Inre Maizoeol^i 439 F,2d 220, 223, 169 USPQ 267, 269 (C.C.P.A. 1971); Weil v. 
Bote, 601 F.2d 551. 555, 202 USPQ 447, 450 (C.C.P.A. 1979)): 

[A] specification disclosure which contains a teaching of 
the manner and process of making and using the invention in tenns 
whi<di correspond in scope to those used in dcscribii^ and defining 
the subject matter sought to be patented must be taken as in 
compliance with the enabling requirement of the first paragraph of 
§112 unless there is reason to doubt the objective truth of the 
statements contained therem which must be relied on for enabling 
support...." "[A]ny party making the assertion that a U.S. Patent 
specification or claims fiiils, for one reason or another, to comply 
with §112 bears tiie burden of persuasion in showing said lack of 
compliance. 

In this regard the Office Action foils to provide a reason to doubt the objective truth of 
the statements in the specification regarding "building a Ust of a sequence of said static and 
dynamic structures" and "building multiple repeating dynamic structures at runtime", and as 
such, the rejections are prima facie defective. 

The CCPA has further indicated in InreAi^^^M^ 537 F.2d 489, 190 USPQ 214, 219 

(C.C.PA. 1976) (citing In re Aimbnater. 512 F.2d 676, 185 USPQ 152 (C.C.P.A. 1975)): 

[T]he PTO has the burden of giving reasons, supported by 
the record as a whole, why the specification is not enabling.... 
Showing that the disclosure entails undue experimentation is part 
of the PTO's initial burden. ... 

In this regard, the Office Action feils to provide a reason why undue experimentation 
would be required with respect to "building a list of a sequence of said static and dynamic 
structures" and "building multiple repeating dynamic structures at runtime", and as such, the 
rejections tac prima facie defective. 
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Whether the specification is enabling is judged with respect to whether one of ordinary 
skiU in the art would properly understand how to make and use the invention as it is described in 
the specification and drawings. TTxe detemiination of the level of oidinary skiU has been 
articulated by the Federal Circuit in Custom Accessories Inc. v. Jeffrev-Allan InAu^ 807 F.2d 
955, 1 USPQ 2d 1196, 1201 (Fed. Cir. 1986): 

The person of ordinary skill is a hypothetical person who is 
presumed to be aware of all the pertinent prior ait. The actual 
inventor's skill is not determinative. Factors that may be 
considered in determining level of skill include: type of problems 
encountered in art; prior art solutions to those problems; rapidily 
with which innovations are made; sophistication of the technology; 
and educational level of active workers in the field. Not all such 
Victors may be present in every case. 

With respect to the above, pages 1-2 of the Applicants' specification, as originally filed, 
indicates what problems are encountered in the prior ait as well as what some of the prior art 
solutions are with respect to the encountered problems: 

A typical extensible Markup Language (XML)-based 
transaction in a business-to-business ^2B) environment involves 
combining transaction infonnation such as name, address, social 
security number, credit card number, etc. fi-oni various data 
sources. Some of this infonnation is fixed for a given trading 
partner, transaction, and set of business rules. Existing solutions 
Store the trading partner rules and transaction infonnation in a 
database or file or in an XML foraiat, which is then read and 
translated to the output XML fomiat in the computer system 
tunmng the B2B exchange. Unfortunately, in a heavy B2B 
transaction environment, the incremental costs associated with 
reading and translating the stored information can be significantly 
high. 

XML files that cany B2B messages have varied static and 
(fynamic content dependent on the trading partner profile (TPP). 
Within a given business message in an XML format, different 
business partners require different views of data as defined by the 
TPP. The result is an XML file that has static sections that are 
structurally the same but wiA different views of data. However. 
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biulding a static structure has several disadvantages including a 
redundant/repetitive code, and that the static structure and content 
are intertwined with the business logic. Other disadvantages are 
that the static structure is not modular, which leads to limited 
reusability, and is not flexible, whereby changes mi^t involve 
logic ftom several TPPs. Additionally, static stmctures are not 
scalable, wherein die introduction of a new TPP in the electronic 
B2B exchange requires additional code to be read, entered, and 
stored. Also, "building" an XML file for a given transaction is 
slower and inefficient because of building the aforementioned 
static portion and because of runtime inefSciencies, 

Conventional techniques relating to different areas of XML 
technology exist. For example, XML techniques have been 
previously described for (1) XML construction - in U.S. Patent 
6,635,089 issued to Burkett et al; (2) XML stor^e - in U.S. Patent 
6,643,633 issued to Chau et al.; (3) XML data integrity - in U.S. 
Patent 6,687,848 issued to Najmi; and (4) XML translation - iii 
U.S. Patent 6,601,071 issued to Bowker et al., the complete 
disclosures of which in tiieir entireties, are herein incorporated by 
reference. Howevw, the conventional techniques may not fully 
provide for a solution that provides for XML file construction. 
Structure integrity, and mass customization, which are three 
significant areas requiring a solution as identified by the industry. 

Furthermore, the technological environment of the field of the Applicants' invention (i.e., 

computer-implemcnted systems and methods for improving coding processing in a business-to- 

business environment) at the time of the invention, was fast-paced with new innovations being 

developed witii great rapidity. This is evidenced by the relative closeness in conception 

(evidenced by the relative closeness in flie respective filing dates) of the four prior art patents 

discussed in the Applicants' specification (as provided above) as well as tiie several prior art 

patents listed in tiiose patents as being relevant. Next, the actual level of sophistication of the 

technology related to coding processes in B2B environment at the time of the Applicants' 

invention (2004) was such tiiat several coding techniques and off-the-shelf products were 

available to fiualhate the practical use of the AppUcants' claimed invention. For example, page 9 
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of the AppUcaats' specification, as originally filed, provides, "Generally, custom generated code 
based on XML, Java-based XML paisers and Java-based data access tools, and XML editors 
may be used to implement the method described above." Moreover, page 13 of the Applicants' 
specification, as originaUy filed, provides, "Additionally, the invention utilizes tools and 
plications such as xDoc XML Converter, available from CambridgeDocs, Cambridge. USA, to 
peifonn the transfoimation continuously as needed rather than at install time and tying it with the 
business partner ciiteria." Finally, the educational level of active workers in the field are college 
educated (bachelors and/or masters degrees) engineers and computer scientists having computer 
programming skills. 

In view of the above factors, at the time of the Applicants' invention (2004), the number 
of those individuals of ordinary skiU in die ait, both in the United States and abroad, was 
Stififidetit and the skUl of such individuals to understand the teachings of the Applicants' 
invention as described in the specification and drawings was at an appropriate level to aUow such 
individuals to make and use the Applicants' invention without undue experimentation. To 
fiirther prove this assertion, the Applicants offer the following description of what one of 
ordmary skill in the art would understand within the contejct of the Applicants' invention and 
d^ailed specificatioh/drawings. 

An XML-based transaction involves a combination of static data and dynamic data (at 
transaction execution time) for a given trading partner, transaction and relevant set of business 
roles. Also the static and dynamic data have to be combined in a certain sequence to derive a 
complete XML transaction for that trading partner, to pieserve the structural integrity of the 
XML as per the conespouding document type definition (DTD) format Moreover a set of 
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relaied static data in a transaction is typicaUy grouped into a XML sub-straoture. Similarly a set 
ofdynaniicdatacanbegroupedintoaXMLsub-structuie. A complete XML structuie that 
represents a real business transaction typically comprises of one or more of such static sub- 
structures and one or more occunences of such dynamic sub-structures. Furtheimote the static 
and dynamic components should be linked together in coirect sequence to derive a complete 
XML transaction document. This sequence list must be defined for a trading partner and 
transaction before the said XML transaction can be exchanged with a given trading partne 
Also, the complete XML siructure thus derived by linking static and dynamic sub-structures i 
the correct sequence should be vaHdated against the relevant DTD to validate the integrity of the 
document An example of building such a sequence of XML sub-structures is shovm below, 
which is something that one of ordinary skill in the art (programmer) would be able to 
sufSciently derive given the teachings in the Applicants' specification and drawings, as 
originally filed. 

The following example shows pre-buih static and dynamic structures for a shipment 
transaction. A real-life Purchase Order transaction may contain more elements and sub- 
structures than dq>icted here: 

Pre-built Static XML sub-structure 1 : 

<fromPartner> 

<Name>IBM</Name> 

<OUNS>123456789</DUNS> 
o'fi'0mPartner> 
<toPartner> 

<Name>PartnerA</Name> 

<DUNS>987654321<a3UNS> 
</toPartiiei> 
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Pte-built Dynamic XML sub-stxucture 1 (single occunence with empty tags): 

<Shipment?> 

<DocmnexitID> </ DociiinentID> 

<DocumentDate> </ DocumentDat^ 

<ShipmentType> <SMpmentType> 

<NmnberOfItems> <l Nm]QberOflteins> 
</Shipment> 



Pre-biult Dynamic XML sub-structure 2 (single occurrence with empty tags): 

<ShipmentItenis> 

<PartNumbci> <yPartNumber> 

<PattDescription> </PartDescription> 

<ItenaNumber> </ItemNumbei> 

<ItemQuantity> </ItemQuantity> 

<ExpectedDeIiveryDate> </ ExpectedDeUveryDatO 
</ShipmentItems> 



Pte-built Dynamic XML sub-structure 3 (single occurrence with empty tags): 

<ContainerInfo> 

<ContainerId> </ContainerId> 

<ContainerLevel> </ ContainerLevel> 

<ContainerSize> </ ContainerSize> 
</Containerlafo> 



The following shows a list of sequence of static and dynamic sub-stnictuies associated 
with trading partner called PartaerA for transaction Shipment: 



1 

Followed by 
' ^ — ► 


Static Sub-structure 1 


Dynamic Sub-structure 1 


1 

Foirowed b/ 


Dynamic Sub-structure 2 
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The complete Shipment XML transaction, based on the above list of sequence, will be 

constructed at transaction execution time as follows: 

<ShipinentTransacticn> 
<!&oniPartner> 

<Naine>IBM<;/Name> 

<DUNS>123456789</DUNS> 
</fix)mPartner> 
<toPartner> 

<Nanie>PartocrA<;/Name> 
<DUNS>987654321 </DUNS> 



</toPartner> 
<Sliipment> 



Empty tags fined with 
actuaf business 
v^aluesatruntrma 



<Documentro>SHIP^l</ DocumentID> 

<DocumentDate>2006-01-01</ DocunientDate> 

<ShipmentTyp^0veniight</Sh2pmemType> 

<NumberOfItems>l </ NumberOfltems> 
</Shipment> 
<ShipmentItem$> 

<PartNumber>PN 01/0l</PaitNumbef> 
<PartDe$cription>Saniple Part</PartDe$cription> 
<IteinNuniber>000 1 </[temNumber> 
<ItemQuantity>lOOO</ItemQuantity> 

<ExpectedDeliveryDa1»>2006-01 -02<f ExpectedDelivefyDatb> 
</ShipmentIteins> 
</ShiiMnentTraiisaction?> 

The complete XML transaction thus built will be validated against a relevant Document 
Type Definition (DTD) to validate the structural integrity. 

Furtheimore, one of ordinary skill in the art would readily understand that, given the 
Applicants' specification and drawings, for a specified XML transaction linked to a TPP, the 
transaction-specific business data values are retrieved fix>m various data sources such as database 
and files at execution time. The actual business data values filled in the dynamic sections of the 
XML at execution time can vary fi-om one transaction to another, dependbg on the transaction- 
context Hence, the dynamic sub-structmes of the XML transaction can occur once or multiple 
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times depending on the actual business data values retrieved for that transaction at execution 
time. 

One example can be the shipment transaction, where parts at« shipped fiom a vendor to 

customer, wherein one customer may be shipped one part in a given shipment transaction while 

another customer may be shipped multiple parts. In a simple case, each of llie part detail can be 

represented in one dynamic sub-structure. The Applicants' invention provides for buUding 

dynamic sections with either one instance or multiple instances based on the actual transaction 

values thus retrieved. An example demonstrating multiple occurrences of dynamic structures is 

described below, which would be readily understood by one of ordinary skill in the art. 

This example is based on Shipment transaction example firom above. At transaction 

execution time (runtime), this example assumes that trading partner caUed PartnerA is seart a 

Shipment transaction with 2 items. The computer program as implemented by the Applicants' 

invention builds 2 occurrences of dynamic XML sub-structure 2 (from above), based on the 

actual liansaction data (for 2 shipment items) retrieved from data sources at execution thne. The 

complete XML per this example will look like as follows: 

<ShipmentTransaction> 
<fiomPartner> 

<Name>IBM</Name> 

<DUNS>1234567S9<DX;nS> 
<yfiromPartner> 
<toPartncr> 

<Name>PartnerA</Name> 

<DUNS>98765432l<DUNS> 
. </toPartner> 
<Shipment> 

<DocumentID>SHIP-02</ Documentm> 
<DocumentDate>2006-0 1 -01</ DocumeartDate> 
<ShipmeMType>Ovemight</ShipmentType> 
<NumberOfltems> W NumberOfItems> 
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PA6E18/31'RCVDAT 11)1612(1063:13:53 PM [Eastern Standard riine]*SVR:U8PT0{^^^^ 



11/16/2006 16:13 3012618825 GIBB IP LAW PAGE 18 



</Shipinent> 
<ShipmentItjems>_ 



Notice multiple 
occurrences of dynamic 
staicture Shipmentltems 



<PailNumber>PN 01/0 1 </PartNumber> 
<PartDescription>Sample Part</PartDescriptfon> 
<IteinNumber>000 1 </IteinNiimber> 
<ItemQuantity>1000</ItemQuaiitity> 

<ExpectedDeliveiyDate>2006-01-02<^':^)q)ectedDeliveryDate> 
•^Shipmentlteiiis> 

<ShipinentItenis> '■ — 

<ParlNumbei>PN 02/01</PartNumbeo 
<PanDescription>Second Sample Part<yPartDescriptioit> 
<tei]QNui]Qber>0002</ItemNumber> 
<ItemQuantitj^2000</ItemQuantity> 

<E;q)ectedDeUveryDate>2006-01-02<y ExpectedDeliveryDat^ 
</ShipmMitrteins> 
</Shq)mentTraiisaction> 

The complete XML transaction thus built will be vaUdated against a relevant Document 
Type Definition (DTD) to validate the stractural integrity. 

According to the invention, only static sections and singje-occnrrence dynamic sections 
with empty values are pre-buUt, and the pre-built static and dynamic sections are linked to the 
TPP. Those of ordinary skill in the ait would understand that a static strwture is a pre-built 
XML structure with pr©.fiUed values based on the associated transaction type and trading entity, 
and a dynamic stractare includes pre-built dynamic sections with empty tags and a single 
occurrence of a rqjeating structure. The empty tags and multiple occurrences wiU be built at 
runtime. 

Accordingly, ^ prima facie non-enabling rejection given in the Office Action is 
improper as failing to articulate the requirements fw asserting such a rejection as mandated by 
the Federal Circuit and associated jurisdictions. Furthermore, as demonstrated above, one of 
ordinary skill in the art would clearly understand the Applicants* invention when reading the 
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specification and drawings and inteipreting them in Ught of Hm; prior art and their ordinary skill 
in the technology. In view of the foregoing, the Examiner is respectfuUy requested to reconsider 
and withdraw this rejection. 

m. The Prior Art Rejections 

Claims 1-4, 6, 8-14, 16, and 18-21 stand rejected under 35 U.S.C. § 102(b) as being 
anticipated by Dan, et al. (U.S. Publication No. 2002/0178103), hereinafter referred to as Dan. 
Claims 5, 7, 15. 17, and 22 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Dan in view of Thomas (U.S. PubHcationNo. 2003/0167446). Applicants respectfully traverse 
these rejections based on die following discussion. 

Dan teaches a method for automatmg a contract negotiation between a plujralhy of parties 
over a communications network. The parties communicate and agree upon a negotiation 
protocol before commencing the negotiation in a meta contract that is fomied to govern or 
control the negotiation process. The automatic negotiation may include at least one sub 
negotiation. Machine-executable rules are specified to enable an automatic negotiation to take 
place between servers over a communications network. A successful negotiation may result in 
the fomiation of an electronic commerce contract. Each party may maintain the contract state of 
the overall negotiationj which may take place among two or more parties, wherein at least one 
party may be represented by a broker. Thus, complex negotiations may be handled automatically 
by the inventive method. The negotiation may be conducted semi-automatically to allow for 
human intervention in the negotiation process. 

Thomas teaches a metiiod of recording changes to a markup language file which employs 
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appUcation-defined tags. The changes are recorded in a delta file which is also a markup 
language file providing validation of the recorded changes against substantially the same markup 
language structore as that of the markup language file being changed. Where the original 
maikup language file is an XML file with a DTD, a DTD can be created for the delta file which 
substantially follows the DTD of the original markup language file. Strict compliance of the data 
lecoided in the deha file with the delta DTD provides validation of the changes vrfth respect to 
the original XML file. 

The motivation bdiind the Applicants' invention is that in a B2B environment, 
transaction infoimation is combined using various data sources (database, files, XML fonnat, 
etc, ), and in a heavy B2B transaction environment, the incremental costs associated with reading 
and traoslaling the stored information is significantly high. Accordingly^ the Applicant's 
claimed invention achieves the result of speeding XML constniction in high volume transaction 
aivironment by using pre-bnih static and dynamic structures. 

Furthermore, the AppUcants* claimed invention, as provided in amended independent 
claims 1, 1 1 , and 21 contain features, which are patentably distinguishable from the prior art 
references of record. Specifically, claims 1, 11, and 21, genoaUy provide, in part, 
"... establishing an original pre-defined da t a type definition format for an XML transacrig n^ 
creating a copy of said original pre-defined dat a tvne definition fommt for said XML trai«action; . 
... wherein an occurrence of said runtime of said XMT. transaction ocems when said XMT, 
transaction i$ sent to a trading partner: and f- o nstnictine a final XML structure based on the 
combining pmcess. wherein said final XMT. ^rt m eture is valiriated bv comparin g said fin^l VA^T 
^tnicture against said copy of said orioinal d a ta tvpe definition format for said XML tran<:a>^/^ >' 
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These featuies are neither taught nor suggested in Dan, as admitted on pages 13-17 of the Office 
Action- Furthennore, even if Dan were properly combined with Thomas, they would stiU ML to 
teach the Applicants' claimed invention because of the occurrence of the time of occurrence of 
the combinii^ of the static and dynamic structures occurs at the runtime (i.e., when said XML 
transaction is sent to a trari^^j. w^'fT) tramnrtiitn. Tvhrm- in Hnn thij occuiJ 

during the contract negotiation time (prior to the runtime of the XML transaction). 

Furfliermow!, in Thomas the constructed XML is compared to a pre-established DTD and 
if there is a difiference (delta) between the constructed XML and the pre-established DTD, then 
Thomas changes the DTD (and saves these changes into the DTD) (see Figure 3 of Thomas), 
Conversely, in the Applicants' claimed invention the constructed XML is compared to a copy of 
the pre-estabKshed DTD and if there is a difference between the constructed XML and the copy 
of the pie-estabUshed DTD, then the XML is invahdated f wherein said final XML stmcturft is 
validat^q bv comparing said final XML stm c ture against said copy of said nrip ina^ ij^^ ^ tyj ^ 
definition format for said XML transaetinnV Therefore, in the Applicants' invention if a 
difference exists, then the DTD is not changed, but rather the process is repeated until no 
changes exist 

In other words, to use a simple analogy, if the DTD can be likened to an answer key for 
an exam, and the constructed XML is a student's response to an exam, then in Thomas, if there 
are differences between the answer key and the student's response, (hen the answer key is 
changed. However, in the Applicants' invention, if there are differences between the answer key 
and the student's response, then the student's response is deemed invalidated (i.e., incorrect). 
The differences between the Applicants' invention and Dan can be graphicaUy shown as foUows: 
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Additionally, Dan handles XML as a fomi template to be filled: 



Values are filled in for static sections of XML 



<XML> 

<Start Static Group 1> 
<Static Fieldl> 
<Static Pield2> 
<End Static Groupl> 
<Static Field 3> 

<Non.static Fieldl> f 'TEmpty" tags arc left for non-static/^'negotiable" fields 

<Static Field 4> 
<Noja-static Field2> 
<EiidXML> 



} 



Thus, Dan uses a fomx template with some values filled in and some values left blank. 
Accordingly, there is no intelligence in Dan's approach to differentiate if a field is single 
occurrence, multiple occurrence, etc. Conversely, the Applicants' break the XML into pieces 
and string them together via an external list: 



<XM1> 
<Start Static Group 1> 
<StaticFieldl> 
<Static Field2> 
<End Static Groupl> 
<Static Field 3> 



<Non-static Fieldl> 
<Single Occurrcnce> 



<Static Field 4> 



<Non-$tatic Field2> 
<Single OccurTence> 
<EndXML> 



XML Structure A 



XML Structure 



XML Structure 



XML Structure 




LIST: 

LXML Structure A 

2. XML Structure B 

3. XML Structure C 

4. XML Structure D 



Structure is physically kept 
in db/file/storage. 

- The LIST defines the sequence 
in which the Structures need to be 
assembled to fortn the final XML 
at transaction runtime. 
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The Applicants provide for pre-building of static structures of an XML transaction. The 
Office Action suggests that Dan teaches this as follows; 

- Hie profile serves as the starting point of a negotiation by providing an initial 
version of a contract document (paragraph 30). 

- The profile may be expressed, as an XML document whose contents may be 
incorporated into a contract (Paragraph 34). 

- One example of a contract template is an almost complete electronic contract 
document with a few fields left blank (Paragraph 34). 

However, Dan's approach leads to finalizing the structure of a contract document. 
Conversely, the i^licants' approach occurs the stmcture of the XML is finalized between 
patties. Dan's ^>proach entails filling a template with values. The template, even if it 
incoiporates an XML, remains as a single structure. Clonversely, in the Applicants' apprt«ch, 
the XML is broken down into fragments of several static and dynamic structures. 

Next, the Applicants provide for classifying the dynamic structures of the XML 
transaction with empty tags and single occurrence classifiers for repeating dynamic structures. 
The Office Action suggests that Dan teaches this as follows: 

- Negotiable field 1 023 or 1024 may be treated as blank that may be completed by 
the negotiating party (Paragraph 35). 
However, Dan shows the method of leaving few fields blank in a document ten^laie, 
yyhile it is being exchanged between partners. In others words, the document is transmitted wilh 
blank values. Conversely, the Applicants' ^roach does not involve leaving fields blank in a 
transaction when exchanged between partners. Additionally, Dan talks only about blank fields. 
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Whereas, the Applicants provide a jnechanism where an entire sub-structure within an XML can 
be left wifli empty tags with attributes embedded in the XML itself or as an attribute of the list 
iiuiicating if the entire strucftire is a single or repeating occurrence. Furthermore, as indicated 
above, Dan's approach has no intelUgence on whether the "blank" field is to be filled. 
Conversely, the Applicants mark the pieces of XML that are truly dynamic and provide a method 
for empty tags, and classifiers to indicate if the structure is single occurrence, multiple 
occurrences, etc. 

Next, the Applicants provide for building a list of a sequence of static and dynamic 
structures. The Office Action suggests that Dan teaches this as follows; 

- A set of sequendng rules 180 may be provided m meta contract 110 to ensure that 
the various negotiation actions are being issued in the correct order (Paragraph 
32). 

However, the AK)licants list is different fix)m that taught in Dan as described above. 
Moreover, Dan's use of sequencing rules is fundamentally different than the Applicants' 
approach. Dan's sequencing rules refer to the choreogr<^hy of a series of negotiation action.^ as 
part of a lonR-rnnninp transaction. Dan himself defines the various Action Names in his 
^ Paragmph 42. Hiis clearly demonstrates that Dan does not teach the Applicants' claimed 

invention. 

Next, the Applicants provide for linking the list to a type of XML transaction and a 
predetermined trading partner profile. The Office Action suggests that Dan teaches this as 
follows: 
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- Starting defimtions and values for these types of infomialion in the negotiated 
contract may be provided in a TP A template or party profile (Paragraph 32). 

Dan provides starting definitions and values fix>m a TPA tOTiplate or party profile. For 
example, Dan might derive starting values from the TPA template for Company ABC, However, 
the Applicants' approach links the list of static and dynamic parts to the defined Trading Partner 
Profile and specific transaction type. For example, the Applicants could link the list to Company 
ABC and a shipping transaction type. Dan does not and cannot accomplish this. 

Furthermore, the Applicants provide for combining the static structures with the dynamic 
structures at a runtime of the XML transaction based on the sequence, the type of XML 
transaction, the partmer profile, and the dynamic structures of XML transaction. The Office 
Action suggests that Dan teaches this as follows: 

- One example of a contract template is an almost complete electronic contract 
document with a few fields left blank (Paragraph 34). 

- Once a contract template of Dan is sent for negotiatiotk, it contains fields that are 
set and non-negotiable, and fields that are negotiable. 

However, Dan teaches how to fill a form with some fields filled in and some fields left 
blank. Dan's teaching transmits a template with blank and non-blank fields. Moreover, Dan 
does not teach how to break an XML transaction, and classify them as static and dynamic 
components: Furthermore, Dan does not teach how to dynamically fill values in an XML to 
construct a complete XML prior to transmission. Rather, Dan teaches how to send blank tags to 
be optionally filled by receiving partners. Moreover, Dan's teaching does not assemble the 
complete XML (wilh no. blank field/structures) prior to tt^mission. Dan's teaching involves 
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two or more partners to fill tfie blank fields. Conversely, the Applicants' approach involves 
breaking and assembling the XML within a single p.artner*s environmrat before transmitting the 
infonnation to another partner. Mcweover, the Applicants combine static and dynamic structures 
at runtime, with actual transaction values, at runtime, when the complete transaction is sent to the 
partner. Additionally, Dan's method talks about building an almost complete clecttonic oontxact 
document prior to runtime. In the Applicants' ^proach, actual transaction values can differ for 
each individual transaction (ex. shipped product, quantity and dollar value in today's transaction 
can be different ftom the very next instance of the transaction for the same partner, and same 
transaction type). 

Furtheraiore, the Applicants provide for pre-building of the static structures to occur prior 
to runtime of the XML transaction. The Office Action suggests that Dan teaches this as foUows: 

- The profile serves as the starting point of a negotiation by providing an initial 
version of a contract document (Paragraph 33). 

- The profile may be expressed, as an XML document whose contents may be 
incorporated into a contract (Paragraph 34). 

- One example of a contract template is an almost complete electronic contract 
document with a few fields left blank (Pamgraph 34). 

- Contract of Dan runs once flie negotiation phase begins to fill in the initial blank 
negotiable fields 1023 and 1024. 

However, as mentioned Dan teaches how to fill a form with some fields filled in and 
transmit a template with Wank and non-blank fields. But. Dan does not teach how to break an 
XML transaction and classify the static components, Dan teaches how to fill fields in a template 
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as part of the process of building and transmitting an instance of the XML. This entire process 
occurs once per document transnodssion. Conversely, the Applicants' approach involves two 
distinct events. In a first phase, the static coraponrait is classified and filled in. The phase first 
occurs one time for a partner and transaction type. The second phase occurs every time a 
transaction is sent to a partner, wherein the static structures are combined with the dynamic 
structures^ according to the sequence defined by the list. 

Next, the Applicants provide for filling the empty tags of the dynamic structures with 
business data values. The QfGce Action suggests that Dan teaches this as follows: 

- Negotiable 1 023 or 1024 may be treated as a blank that may be completed by the 
negotiating party (Paragraph 35). 
However, again, Dan teaches how to fill a form with some fields filled in and transmit a 
template wiA blank and non-blank fields- Dan does not teach how to break an XML transaction 
and classify the static and dynamic components. Rather, Dan teaches how to fill fields in a 
template as part of the process of building and transmitting an instance of the XML. Again, this 
en^ process occurs once per document transmission. Conversely, the Applicants' approach 
involves two distinct steps. In the first phase, the static component is classified and filled m. 
The fuist phase occurs one time for a partner transaction type. The second phase occurs 
every time a transaction is sent to a partner, wherein the dynamic structures are automatically 
filled based on the associated pre-defined business logic, and the static structures are combined 
with the dynamic structures according to the sequence defined by the list Moreover, the 
Applicants' ^jproach provides the manner of filling actual business data values in the dynamic 
sections of an XML to construct a coniplete XML prior to transmission. Whereas, Dan teaches 
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how to send blank tags to be optionally filled by receiving partners. Furtheimore, the 
Applicants' approach provides for expanding dynamic structures (ex. multiple occurrences) at 
runtime, based on actual transaction business data values occuiring at runtime. 

Next, the Applicants provide for creating a copy of a pre-defined data type definition 
fonnat comprising the XML format The Office Action suggests that TTiomas teaches this as 
follows: 

- The processor reads 12 the document type definition (DTD) of the first XML file 
and creates copy 13 of the DTD. 
However, the Applicants use the DTD to validate the final XML after combining static 
and dynamic structures, and filling actual transaction business data values at runtime. As 
previously mentioned, the maimer of comparison and validation is different between Thomas the 
Applicants' claimed invention. 

In view of the foregoing, the Applicant respectfiilly submits that the collective cited {wior 
art dp not teach or suggest the features defined by amended independent claims 1 , 1 1 , and 21 and 
as such, claims 1,11, and 21 arc patentable over Dan alone or in combination with Thomas. 
Further, dependent claims 2-6, 8-10, 12-16, 18-20, and 22-24 are similarly patentable over Dau 
alone or m combination with Thomas, not only by virtue of their dependency fixim patentable 
independent claims, respectively, but also by virtue of the additional features of the invention 
they define. Thus, the Applicant respectfiilly requests that fliese rejections be reconsidered and 
withdrawn. Moreover, the Applicant notes that all claims are properly supported in the 
specification and accompanyii^g drawings* In view of the foregoing, the Examiner is 
respectfully requested to reconsider and withdraw the rejections. 
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IV. Formal Matters and Conclusion 

With respect to the rejectiom to itxc drawings, the specification has s been amended, to 
overcome these rejections. In view of the foregoing, the Examiner is respectfully requested to 
reconsider and withdraw the rejections to the drawings. With respect to the rejections to the 
claims, the claims have been amended, above, to overcome these rejections. In view of the 
foregoing, the Examiner is respectfully requested to reconsider and withdraw the rejections to the 
claims. 

In view of the foregoing, Applicants submit that claims 1-6, 8-16, and 18-24, all the 
claims presently pending in Ae application,, are patentably distinct from the prior art of record 
and are in condition for allowance. The Examiner is respectfully requested to pass die above 
application to issue at the earliest possible time. 

Should the Examiner find the application to be other than in condition for allowance, the 
Examiner is requested to contact the undersigned at the local telephone number listed below to 
discuss any other changes deemed necessary. Please charge any deficiencies and <a^dit any 
overpayments to Attorney's D^sit Account Number 09-0456. 



2568-A Riva Road, Suite 304 
Annapolis, MD 21401 
Voice: (301) 261-8625 
Fax:(301)261-8825 
Customs Number: 29154 
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